The Third Generation Project Partnership (3GPP) has developed the System Architecture Evolution (SAE) as the core network architecture of its future and Long Term Evolution (LTE) wireless mobile telecommunications standard. The main component of the SAE architecture is the Evolved Packet Core (EPC); see “Architecture enhancements for non-3GPP Accesses,” 3GPP TS 23.402). The LTE/SAE network includes network entities supporting the user and control planes.
An ongoing trend within telecommunications is the convergence of fixed and mobile networks, which is known as Fixed Mobile Convergence (FMC). The trend of evolving networks using IP-based technologies is common for fixed and mobile networks, which makes the convergence easier. By utilizing FMC, mobile and fixed network operators will be able to utilize their network resource more efficiently, which leads to a reduction of capital and operational expenditure (CAPEX and OPEX). For instance, when a user is running an IP-based application such as Multimedia Telephony (MMTel) inside their home, it is more efficient to utilize broadband connectivity of a fixed access network rather than a wireless access network.
Residential networks have been important to the success of FMC because they are the most commonly used fixed network access by ordinary users. Therefore, it is important to be able to connect mobile phones to the EPC through a residential network. The term User Equipment (UE) can be used in place of the term mobile terminal or mobile phone. The term UE is familiar in the 3GPP documentation, and is intended to refer to any piece of equipment that is configured to access the internet; it would include, for example and without limitation, mobile telecommunication devices, portable or handheld computing devices and desktop or installed computers.
3GPP defines mobile 2G/3G/LTE accesses and “non-3GPP accesses” (TS 23.402), wherein the latter can be a fixed network. The BBF (Broadband Forum, the standardization organization for the fixed access; see www.broadband-forum.org/) defines an architecture for fixed networks. There is an ongoing joint work item on FMC between these two organizations (3GPP TR 23.839, now moving into TS 23.139, and BBF WT 203). Many UEs address the FMC trend by providing multiple radio interfaces: one interface to connect to a 2G/3G/LTE access and a WiFi interface to connect to a fixed network.
There are a number of ongoing work items on FMC. In FMC, a dual-radio UE is generally assumed. The UE has one radio interface for the 3GPP access (e.g. LTE), and one radio interface for the fixed access (e.g. WiFi). In 3GPP, “Study on Support of BBF Access Interworking” (BBAI) covers interworking between 3GPP (the standardization organization for mobile networks) and BBF (the standardization organization for fixed networks) (3GPP TR 23.839, TS 23.139, BBF WT 203). Another work item in 3GPP, “Study on S2a Mobility based On GTP & WLAN access to EPC” (SaMOG) covers the standardization of a 3GPP network interworking with a WiFi radio access (3GPP TS 23.852). Additional standardization activities are ongoing in the WiFi Alliance. SaMOG is specific to S2a, but not specific to BBF.
In the WiFi Alliance, one of the focus areas is hotspots, such as public hotspots. Therefore, in addition to the residential networks described above, hotspots are increasingly becoming key to the success of FMC.
A 3GPP UE can attach to a non-3GPP access network (e.g. a fixed network) and connect to one or more Packet Data Networks (PDNs) via the S2 interface [3GPP TS 23.402]. The S2 interface comes in three types: S2a, S2b and S2c. The latter two overlay the non-3GPP access network and do not impact it. S2a is a more converged solution that does impact nodes in the non-3GPP access network. In S2a, the non-3GPP access network is seen as trusted; the non-3GPP access network is therefore denoted as TNAN (Trusted Non-3GPP Access Network). Where the TNAN uses Wireless LAN (WLAN) as the radio technology towards the UEs, the TNAN is denoted as TWAN (Trusted WLAN Access Network).
S2a over TWAN is now standardized in 3GPP (Chapter 16 of 3GPP TS 23.402). At present (3GPP Release 11), S2a over TWAN is restricted to support only a single PDN connection per UE. Also, the UE cannot indicate an Access Point Name (APN) and handover is not supported. This way, S2a over TWAN does not impose any requirements on the UE; in other words, an “unmodified UE” can be used, which increases time-to-market for the S2a solution.
FIG. 1 of the accompanying drawings is a schematic block diagram providing an architecture overview, illustrating a UE 2 connecting to a 3GPP domain 4 via a TVVAN 6. The TWAN 6 comprises a Residential Gateway (RG) 8, an Access Node (AN) 10 and a gateway node denoted as a TWAN Access Gateway (TWAG) 12. The 3GPP domain 4 comprises one or more PDN Gateways (PGWs) 14.
In S2a, there is a General Packet Radio Service (GPRS) Tunnelling Protocol (GTP) or Proxy Mobile IP (PMIP) tunnel for each PDN connection between the TWAG 12 (e.g. a BBF Border Network Gateway (BNG)) in the TWAN 6 and the 3GPP PGW(s). Each PDN connection is anchored in a 3GPP PGW 14. The UE 2 receives one IP address (or prefix for IPv6) for each PDN connection, and it is the PGW 14 that assigns the address. Similarly, between the UE 2 and the TWAG 12 a point-to-point link is provided in order to separate the traffic from the different UEs and PDN connections.
A point-to-point link can be considered to be a protocol that provides a logical direct connection between two networking nodes. A data frame sent from node A via a point-to-point link to node B will not pass a node C. Note that a “point-to-point link” is a logical concept and can be implemented in several ways. The network between the UE 2 and the TWAG 12 would generally be Ethernet based, and examples of a point-to-point link between the UE 2 and TWAG 12 are: a L3 tunnel (e.g. Internet Protocol Security (IPsec) or IP-in-IP), and a L2 tunnel (e.g. L2TP).
The per-UE point-to-point link works satisfactorily in 3GPP Release 11 when there is a restriction on a single PDN connection per UE over TWAN. However, the present applicant has appreciated that an extension is needed to support multiple PDN connections per UE.
In particular, it has been appreciated that there could be a situation where a set of one or more PGWs assign the same IP address for different PDN connections. This could occur where, for example, there are two PDNs connections relating respectively to two closed corporate networks, each with their own addressing scheme. Each PDN might be served by a different PGW, and each PGW might be managed by a different operator. The 3GPP domain(s) and the UE 2 are designed to handle such an overlap without any issue. However, a problem is that the TWAG 12 will no longer be able to map upstream traffic to the correct GTP/PMIP tunnel.
It should be noted that the likelihood of such a problem occurring in a real deployment is small; most UEs 2 will only use a single PDN connection, and the IP addressing schemes of different PDNs will in most cases not overlap. However, the problem can and will occur without a solution, and the applicant has appreciated the desirability of addressing this issue.
There are typically two scenarios where such a problem of overlapping or clashing addresses when a UE access a 3GPP core network via a non-3GPP access network can arise. In both scenarios, a dual-radio UE is assumed; the UE 2 has one radio interface for a 3GPP access (e.g. LTE), and one radio interface for a non-3GPP access (e.g. WiFi).
A first scenario is illustrated schematically in FIG. 2 of the accompanying drawings. In the first scenario, the UE 2 is initially connected to a 3GPP access 16, and already has overlapping addresses in the 3GPP access 16, or has an address in the 3GPP access 16 which overlaps with an address already assigned in the non-3GPP access (TWAN) 6. As mentioned previously, overlapping addresses in the 3GPP access 16 presents no problem; 3GPP by design allows for such a situation. However, a problem occurs when the UE 2 performs a handover to the non-3GPP access 6.
In a second scenario, the UE 2 is attached to a non-3GPP access 6 and opens a new PDN connection. The new address for that PDN connection overlaps with an existing address in the second scenario.
In release 11, a per-UE point-to-point link between the UE 2 and the TWAG 12 is assumed. In most cases, the UE IP address in a packet's header will be sufficient to correlate that packet to an individual PDN connection. However, there are a few situations where this is not possible:
(a) Two or more PDN connections from one UE 2 might have the same IP address. This is in particular possible if these PDN connections are towards different IPv4 PDNs.
(b) Downlink (link layer) broadcasts do not include a specific UE 2 target IP address. An example of such packet is an IPv6 router advertisement.
(c) Uplink (link layer) broadcasts do not include a specific UE 2 source IP address. Such packets are for example used for service discovery.
(d) Downlink IP multicast does not include a specific UE 2 target IP address. Such packets may for example be sent from a server in a PDN.
In order to support multiple PDN connections per UE 2 over TWAN, it has been previously suggested maintaining a single point-to-point link per UE 2, and differentiate PDN connections based on UE IP address and/or UE MAC address. However, these solutions can be considered to impose functional restrictions and/or high impact to the UE 2.
It has also been previously proposed to remove completely the notion of multiple PDN connections in the UE 2, and leave it up to the network to route traffic to different PDNs. One example of such solution is disclosed in IETF Internet-Draft “Multiple APN Support for Trusted Wireless LAN Access”, draft-gundavelli-netext-multiple-apn-pmipv6-01, available at datatracker.ietf.org/doc/draft-gundavelli-netext-multiple-apn-pmipv6. However, such a solution can be considered to break the current 3GPP architecture.
A need exists to provide multiple concurrent services over WLAN. For example when WLAN is used to provide access to cellular data networks, it is desirable to provide access to multiple PDNs (packet data networks). This capability is currently done on 3G/4G networks where e.g. IP Multimedia Subsystem (IMS) and Internet access can be simultaneously provided. Each of these services is identified via their APNs. Further the IP address spaces for each of those services may overlap, making IP address resolution of the services impossible.
Some approaches to provide multiple concurrent services over WLAN have been proposed, but there is currently no existing way of implementing them. Currently there are no means to manage PDN connections over “native” Wi-Fi Access. Layer-3 tunneling solutions such as IPsec can be used but this has certain disadvantages. For example, L3 tunneling solutions are typically transparent to the underlying WLAN access network and thus have limitations in the amount of Quality of Service (QoS) control that can be achieved. Furthermore, there is more overhead involved. In addition, L3 solutions are also not backwards compatible with S2a-over-TWAN solution specified in 3GPP rel-11.
For native WLAN access, Dynamic Host Configuration Protocol (DHCP) is typically used to request an IP address. However, DHCP is not a suitable protocol for managing PDN connections, primarily since there is no clear means to tear down an IP connection. Furthermore, terminal vendors are reluctant to modify DHCP implementations in the terminal in order to enhance them with additional functionality. DHCP is an old protocol and the implementations may not be easy to manage or may not even be fully under the terminal vendor's control.
Tunneling solutions below L3 solve these problems. Each tunnel carries a PDN connection. Several such solutions have been proposed, but these only describe the (user plane) traffic separation mechanism once the tunnel is setup. There is no known mechanism for setting up such tunnels.